Payment Initiation Service.adoc

Payment Initiation Service

The support of this service at the XS2A interface is mandatory. Transactions according to this use case can be used to initiate a single payment in form of a credit transfer from an account of the PSU to an account of the payee.

While the transaction at the XS2A interface is initiated by the TPP, it must first be initiated by the PSU at the PSU – TPP interface. The ASPSP will reject the transaction if the TPP cannot be identified correctly at the XS2A interface and/or if it does not have the role PISP. Subject to the decision of the ASPSP, strong customer authentication of the PSU has to be executed.

Current version of the XS2A Interface supports the following types of payments:

• Single payment;

• Future dated single payment;

• Bulk payment;

• Periodic payment.

Multipart periodic payment uses boundary from request header Content-Type: multipart/form-data; boundary=gc0p4Jq0M2Yt08jU534c0p or default --AaaBbbCcc otherwise when it is stored to CMS database. Resource get payment information returns such payment with boundary delemiters.

Country validation

According to BG Specification every country can have their local requirements for information included in the Payment Request. Payment validation on XS2A side can support different countries.

It is up to ASPSP to decide the for which countries payment validation will be performed. Parameter "countryValidationSupported" in the ASPSP-Profile, defines for which country the payment is validated.

SCA Approaches fo PIS

Payment Initiation Service in Redirect Approach

Figure 1. Payment Initiation in Redirect Approach, implicit authorisation mode

Figure 2. Payment Initiation in Redirect Approach, explicit authorisation mode

Payment Initiation Service in OAuth2 Approach

Figure 3. Payment Initiation in OAuth Integrated

Figure 4. Payment Initiation in OAuth Pre-step

Payment Initiation Service in Embedded Approach

Figure 5. Payment Initiation in Embedded Approach, implicit authorisation mode

Figure 6. Payment Initiation in Embedded Approach, explicit authorisation mode

Payment Initiation Service in Embedded Decoupled Approach (Decoupled approach as a second SCA factor)

Figure 7. Payment Initiation in Embedded Decoupled Approach, implicit authorisation mode

Figure 8. Payment Initiation in Embedded Decoupled Approach, explicit authorisation mode

Payment Initiation Service in Pure Decoupled Approach

Figure 9. Payment Initiation in Pure Decoupled Approach, implicit authorisation mode

Figure 10. Payment Initiation in Pure Decoupled Approach, explicit authorisation mode

Payment statuses

Payment transaction status is synchronised in bank’s database and in CMS. When payment data with payment transaction status is given from ASPSP, status will be updated in CMS, even if it is already finalised. There is endpoint in cms-aspsp-api to set payment data with payment transaction status directly from ASPSP to CMS.

Status settlement:

• Not confirmed with SCA payments obsolete after a certain period. Payment Transaction Status becomes "rejected" and Sca Status for dedicated payment authorisation becomes "failed";

• In case TPP tries to initiate new authorisation for expired payment, XS2A sends the response with HTTP code 403 RESOURCE_EXPIRED;

• In case of usage non-existent payment-id XS2A sends response with HTTP code 404 RESOURCE_UNKNOWN.

The transaction statuses of the payment initiation resource which are defined as Finalised:

• Cancelled (Payment initiation has been cancelled before execution);

• Rejected (Payment initiation or individual transaction included in the payment initiation has been rejected);

• AcceptedSettlementCompleted (indicating that the money has been booked already from the debtor account).

After setting finalised status for payment:

• status isn’t allowed to be changed in CMS any more (except the case when ASPSP updates is directly in CMS);

• new authorisation sub-resource can’t be created;

• cancellation can’t be proceeded.

Payment Cancellation

The support of this use case at the XS2A interface is optional.

A TPP may execute a transaction according to this use case to cancel a (still pending, with payment status not finalized) payment, which has been initiated before. Also future dated payments and recurring payments may be cancelled.

Note	It is up to the ASPSP to decide if a given payment can still be cancelled or not.

Depending on SpiPaymentCancellationResponse properties transactionStatus and cancellationAuthorisationMandated:

• XS2A starts authorisation process of payment cancellation only for authorised payments (which were sent and accepted by ASPSP);

• When payment is finished (has one of transaction statuses Cancelled, Rejected, AcceptedSettlementCompleted) there isn’t possibility to cancel it or to proceed payment cancellation authorisation flow. In this case XS2A sends the response with HTTP code 400 FORMAT_ERROR and output "Payment is finalised already and cannot be cancelled";

• If the payment is initiated and authorisation is not finished yet, then it is not yet sent to ASPSP and cancellation will be done without authorisation, even if ASPSP supports authorisation for cancellation of payment.

Table 1. Payment Cancellation Authorisation Mandated in Profile and in SpiPaymentCancellationResponse

	value	value	value	value
Profile: paymentCancellationAuthorisationMandated	false	true	false	true
SpiPaymentCancellationResponse: cancellationAuthorisationMandated	false	true	true	false
	delete without authorisation	with authorisation	with authorisation	with authorisation

SCA Approaches for Payment Cancellation

Payment Cancellation Service in Redirect Approach

Figure 11. Payment Cancellation in Redirect Approach, implicit authorisation mode

Figure 12. Payment Cancellation Service in Redirect Approach, explicit authorisation mode

Payment Cancellation Service in Embedded Approach

Figure 13. Payment Cancellation in Embedded Approach, implicit authorisation mode

Figure 14. Payment Cancellation in Embedded Approach, explicit authorisation mode

Payment Cancellation Service in Embedded Decoupled Approach (Decoupled approach as a second SCA factor)

Figure 15. Payment Cancellation in Embedded Decoupled Approach, implicit authorisation mode

Figure 16. Payment Cancellation in Embedded Decoupled Approach, explicit authorisation mode

Payment Cancellation Service in Pure Decoupled Approach

Figure 17. Payment Cancellation in Pure Decoupled Approach, implicit authorisation mode

Figure 18. Payment Cancellation in Pure Decoupled Approach, explicit authorisation mode